A. Computing Systems
FIG. 1 shows an embodiment of a computing system 100. The computing system includes a Central Processing Unit (CPU) 101, a cache 102, memory and I/O control 103 and a system memory 104. Software instructions performed by the computing system (and its corresponding data) are stored in the system memory 104 and cache 102 (where frequently used instructions and data are stored in cache 102). The software instructions (together with corresponding data) are executed by the CPU 101. The memory controller portion of the memory and I/O control 103 is responsible for managing access to the system memory 104 (which may be used by functional elements other than the CPU 101 such as the graphics controller 105 and various I/O units).
The graphics controller 105 and display 106 provide the computer generated images observed by the user of the computing system 100. The I/O controller of the memory and I/O control function 103 is responsible for managing access to the system memory 104 (and/or CPU 101) for various I/O units 1081 through 108N and 109, 111, 113 and 115. I/O units are typically viewed as functional units that send/receive information to/from the computing system (e.g., a networking adapter, a MODEM, a wireless interface, a keyboard, a mouse, etc.) and/or functional units used for storing the computing system's information within the computing system 100 (e.g., a hard disk drive unit).
Various I/O units are frequently found within a computing system; and, moreover, various types of interfaces for communication between an I/O unit and the I/O control function are frequently found within a computing system. Often, these interfaces are defined by an industry standard. The exemplary computing system architecture of FIG. 1 shows a system bus interface 107 into which different I/O units 1081 through 108N may be plugged; and, different interfaces 110, 112, 114 and 116. Each of the different interfaces 110, 112, 114 and 116 is drawn in FIG. 1 as having its own corresponding I/O unit 109, 111, 113 and 115.
Note that a different number of interfaces may be entertained from computer system to computer system; and, different interface types (e.g., in terms of the maximum number of I/O units per interface, interfacing technique, etc.) may be entertained from computer system to computer system. As just one possible implementation, using the computing system of FIG. 1 as a template: 1) system bus 107 is a PCI bus; 2) interface 110 is a serial port; 3) interface 112 is a USB interface; 4) interface 114 is a serial interface; and 5) interface 116 is an IDE interface (or other storage device interface)
B. Computing System State Diagram
FIG. 2 shows a prior art state diagram for a computing system. An embodiment of the operating states observed in FIG. 2 may be found in the Advanced Configuration and Power Interface (ACPI) Specification, Revision 2.0a dated Mar. 31, 2002 (and published by Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd., and Toshiba Corporation). Although the ACPI specification is recognized as describing a large number of existing computing systems, it should be recognized that large numbers of computing systems that do not conform to the ACPI specification can still conform to the operating state configuration observed in FIG. 2. As such, the description of FIG. 1 corresponds to a more generic description that the ACPI specification conforms to.
According to the depiction of FIG. 2 a first state 201, referred to as the “normal on” state 201, is the normal operating state of the computer (i.e., the state of the computer when it is actively powered and is being (or is ready to be) used by a user). Within the ACPI specification, the “normal on” state 201 is referred to as the “GO” state. A second state 202 refers to any of one or more states where the computing system is recognized as being “off”. The ACPI specification recognizes two such states: a hardware based off state (e.g., where power has been removed from the entire system) and a software based off state (where power is provided to the system but the BIOS and operating system (OS) have to be reloaded from scratch without reference to the stored context of a previously operating environment). The ACPI specification refers to the hardware based off state as the “G3” state and the software based off state as the “G2” state.
A third state 203 refers to any of one or more states where the computing system is recognized as “sleep”. For sleep states, the operating environment of a system within the “normal on” state 201 (e.g., the state and data of various software routines) are saved prior to the CPU of the computer being entered into a lower power consumption state. The sleep state(s) 203 are aimed at saving power consumed by the CPU over a lull period in the continuous use of the computing system. That is, for example, if a user is using a computing system in the normal on state 201 (e.g., typing a document) and then becomes distracted so as to temporarily refrain from such use (e.g., to answer a telephone call)—the computing system can automatically transition from the normal on state 201 to a sleep state 202 to reduce system power consumption.
Here, the software operating environment of the computing system (e.g., including the document being written), which is also referred to as “context” or “the context”, is saved beforehand. As a consequence, when the user returns to use the computing system after the distraction is complete, the computing system can automatically present the user with the environment that existed when the distraction arose (by recalling the saved context) as part of the transition back to the normal state 201 from the sleep state 203. The ACPI specification recognizes a collection of different sleep states (notably the “S1” “S2”, “S3” and “S4” states) each having its own respective balance between power savings and delay when returning to the “normal on” state 201 (here, the S1, S2 and S3 states are recognized as being various flavors of “standby” and the S4 state is a “hibernate” state).
A problem with prior art sleep states, however, is that the CPU is unable to perform any useful work. As such, although power savings are recognized, any tasks that may have been useful to perform during the time period over which the computing system was sleep are impossible to implement.